Subject: Encoding for the four SNA sense data objects

From: "R.E. (Robert) Moore (254-4436)" <[email-masked]>
Date: Mon, 23 Oct 95 09:00:37 EDT

With the SIG's indulgence, I'd like to open for discussion one more time
the question of how to encode SNA sense data.  As planned, APPN.MIB.2
reflects the solution we reached last summer for the APPC MIB:  encode
SNA sense data "natively", as OCTET STRING (SIZE 4).  I think we should
consider again, though, the option of encoding sense data as
DisplayStrings of size 8.  Here's why:

1.  Agents shouldn't really care either way, so long as the encoding for
    SNA sense data is (1) documented clearly and (2) the same for all SNA
    sense data objects in all of the SNA MIBs.

2.  Even though they "shouldn't" do it, the fact remains that there are
    existing Management Station implementations that don't respect the
    SMI difference between OCTET STRINGs and DisplayStrings.  Such
    implementations look at the *value* returned for an object, rather
    than to the object's definition, to decide how to display it:  if the
    value contains a printable ASCII character, then the Management
    Station treats it as an ASCII string.  Since SNA sense data can
    contain any values in their last two octets, some of them will be
    garbled by such a Management Station if they are returned as OCTET
    STRING (SIZE 4).

3.  It is especially important that SNA sense data *not* be garbled when
    they are presented to an operator, since they are the most compact
    encoding present in SNA:  one four-byte value (typically) represents
    a very specific error condition, which an implementation takes pains
    to detect and report.  A correct, and correctly displayed, SNA sense
    data will often point directly to a particular problem, saving a
    large amount of time that would otherwise be spent on problem
    isolation.

Given these reasons, I propose that we go back to the DisplayString
encoding for SNA sense data.  If we go this way, we'll have to switch the
sense data objects in the APPC MIB back to DisplayStrings.  The single
sense data object in the SNA NAU MIB, snaLuSessnSenseData, is already (
or is still, depending on how you look at it), encoded as a
DisplayString.  The HPR and DLUR MIBs don't contain any sense data.

Bob Moore